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Abstract. This paper describes a cooperative decision making model comprising six concurrently 
executing domain experts coordinated by a blackboard control expert. The focus application field is 
architectural design, and the domain experts represent consultants in the areas of daylighting, noise control, 
structural support, cost estimating, space planning, and climate responsiveness. Both the domain experts 
and the blackboard have been implemented as production systems, utilizing an enhanced version of the basic 
CLIPS package. Acting in unison as an Expert Design Advisor, the domain and control experts react to 
the evolving design solution progressively developed by the user in a 2-D CAD drawing environment. A 
Geometry Interpreter maps each drawing action taken by the user to real world objects, such as spaces, 
walls, windows, and doors. These objects, endowed with geomelric and non-geometric attributes, are stored 
as frames in a semantic network. Object descriptions are derived partly from the geometry of the drawing 
environment and partly from knowledge bases containing prototypical, generalized information about the 
building type and site conditions under consideration. 


INTRODUCTION 

Commencing in 1987 with the participation of an interdisciplinary team of researchers the CAD 
Research Unit at the California Polytechnic State University, San Luis Obispo, undertook the 
development of a prototype working model of a computer-based environment supportive of the 
design function as it is practised in architecture and engineering. Impetus for the project came 
directly from the shortcomings of current CAD systems that focus almost entirely on the 
production of drawings rather than the design decisions that produced the artifacts represented by 
the drawings. 

The CAD Research Unit team proposed an intelligent computer-aided design system 
(ICADS) model comprising three integrated components: an intelligent CAD DBMS, an Expert 
Design Advisor, and a Multi-Media Presentation Facility (Fig.l). 

The CAD DBMS component provides on-line access to information resources in direct 
support of the design function. From the perspective that design involves predominantly the 
refining, adapting and combining of prototype solutions of previous similar projects, the ICADS 
model includes several knowledge bases in the CAD DBMS component. These knowledge bases 
are intended to capture design context experience and serve as a basis for reasoning during the 
earliest decision-making stages. 

Within the CAD DBMS component the evolving design solution is represented as a 
network of hierarchically related objects. Collectively, these objects provide a comprehensive 
description of the current state of the design solution. Individually, the description of each object 
consists of information units or design entities comprising an integrated set of geometric definitions 
and non-geometric attributes. This information representation drives a network of intelligent design 
tools (IDTs) coordinated within the Expert Design Advisor by a Blackboard Control System. 
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Figure 1. 

Conceptual ICADS Model 


Figure 2. 

Intelligent CAD System Shell 


The availability of appropriate design knowledge is central to any computer-based design 
environment. In this respect the ICADS model is foremost an information management and 
synthesizing system, and may be viewed as a shell that binds together an assortment of internal and 
external design resources (Fig.2). The drawing function, which dominates existing CAD systems, 
assumes the secondary role of providing a medium for visualizing and communicating the design 
decisions that have been made within a largely non-graphical problem-solving context. 

The work described in this paper represents the first version of an ICADS working model 
(Pohl et al. 1988, Myers and Pohl 1989). ICADS DEMOl has been developed mostly with off- 
the-shelf software systems. Where the necessary tools were inadequate, enhancements were added 
and modifications made. The relational DBMS, SQL-RT (Oracle), was found to be entirely 
adequate for accommodating the Building Type, Site/Neighborhood and Reference elements of the 
design knowledge component of the ICADS model. The CLIPS expert system shell, developed by 
the Artificial Intelligence Section at NASA/Johnson Space Center, was used for all parts of the 
Expert Design Advisor (NASA, 1989). Availability of CLIPS source code ('C' language) allowed 
several enhancements to be made to the basic CLIPS package to permit the Blackboard Control 
System to execute in a distributed environment with several CPUs. 

The CAD Research Unit was fortunate to obtain permission from Accugraph Corporation 
(El Paso, Texas) to incorporate its MountainTop computer-aided drawing package in ICADS 
DEMOl. Some modifications were made to this commercially available CAD system to provide 
direct access to the data structure of the drawing currently displayed on the screen. 


THE ICADS EXPERT DESIGN ADVISOR 

The principal component of the ICADS DEMOl model is the Expert Design Advisor, consisting of 
six domain experts (IDTs), the Blackboard Control Expert, two knowledge bases and several 
sources of reference data (Pohl et al. 1989). 










The scope of the implementation environment has been restricted in terms of both the 
breadth of information available to the designer and the range of design functions supported. The 
information resources provided by the working model are drawn from the architectural design 
application area and include Building Type and Site/Neighborhood knowledge bases, as well as a 
Reference database containing material and constructional information. 

A schematic diagram of the ICADS working model is shown in Fig.3. The Expert Design 
Advisor is responsible for the evaluation of the evolving design solution and the resolution of 
conflicts that may arise when solutions in one domain interfere with solutions in another domain. It 
consists of advisory components, a control expert and operational components, as shown below: 

advisory components: Geometry Interpreter 

Access domain expert 
Climate domain expert 
Cost domain expert 
Lighting domain expert 
Sound domain expert 
Structure domain expert 

control expert: Conflict Resolver 

operational components: semantic network of frames 

Message Router 
Attribute Loader 



Figure 3. 

ICADS DEMOl System Diagram 


104 









Central to the operation of the Expert Design Advisor is a semantic network of frames that 
represent the current state of the design solution within the context of the project. The term 
semantic network is used here to refer to a classification framework of design object frames. Each 
frame incorporates slots that may contain several types of information, such as values of geometric 
and non-geometric attributes of the current solution model, and relation linkages (Fig. 4). 

The attribute values represent a fact-list that drives the domain experts and the Conflict 
Resolver. Indeed, attribute slot names have identical counterparts among the fact names in the 
latter. This provides a direct interface mechanism that allows the domain experts and the Conflict 
Resolver to react quickly to any changes in the current state of the design solution. Values in the 
fact-list are derived from two sources: 

1 . Geometric facts describing the geometry of the design solution are extracted by the 
Geometry Interpreter in terms of the nature, physical dimensions and relative locations of 
the following seven design objects: 

FLOOR, SPACE, WALL, DOOR, WINDOW, SEGMENT and SYMBOL 

The SEGMENT object refers to any part of a WALL object that is demarcated either by the 
intersection of another wall or has been drawn by the designer as a distinct wall 
component. The SYMBOL object represents directly by name any closed shape or icon 
within a SPACE object (e.g., column, chair, table). 

2 . Attribute facts describing the context of the project and the non- geometric characteristics of 
the current design solution. These attribute facts are derived from the Building Type and 
Site/Neighborhood knowledge bases, directly or indirectly through the extrapolation of 
several information items. Non-geometric attribute values are included in the fact-list in 
association with the following five design objects: 

PROJECT, NEIGHBORHOOD, SITE, BUILDING and FLOOR 

The differences between the geometric and non-geometric design object sets are entirely 
consistent with the nature of the information they contribute to the fact-list. The design knowledge 
bases that support the design process in the ICADS model encompass a much wider view of the 
design space than can be represented by any instance of the geometric design solution. For 
example, while regional and neighborhood parameters are an important part of the design decision- 
making process they are no longer discemable as discrete information items in the drawing of the 
geometric model. At that level they are embedded under several layers of synthesis and are 
therefore an implicit rather than explicit part of the geometry of the artifact 

In the ICADS working model the distinction between design context and design solution 
has led to the separation of the semantic network of design objects into two logical sections 
(Fig. 5). 

PROJECT DESIGN OBJECT FRAMES: comprising one frame for each design object 
represented in the design program (design specifications), which is a subset of the Building 
Type and Site/Neighborhood knowledge bases. Slots in these frames are used to store non- 
geometric attributes that have either direct equivalents in the Building Type and 
Site/Neighborhood knowledge bases, or are inferred from several values by the Attribute 
Loader. 

SOLUTION DESIGN OBJECT FRAMES: comprising one frame for each (geometric) 
design object analysed by the Geometry Interpreter. Slots in these frames represent the 
geometric descriptions of the particular design object identified by the Geometry Interpreter 
and the solution evaluation results generated by the domain experts under the coordinating 
role of the Blackboard. 
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Figure 5. 

Logical Division of Design Objects 


In the current ICADS working model the slot values of the 'project design object' frames 
cannot be changed by the designer during the design process. They are established by the Attribute 
Loader at the beginning of a design session and remain as static members of the input templates of 
individual domain experts, and to a lesser extent the Conflict Resolver, throughout the design 
session. 


THE DESIGN KNOWLEDGE BASES 

The structure of the Building Type and Site/Neighborhood knowledge bases in the ICADS model 
have been reported previously (Pohl et al. 1988). These knowledge resources are intended to 
capture the experience and standard solution strategies associated with a given building type, and 
the specific conditions of the site and its surrounding environment, respectively. Collectively, they 
provide views of the design project from several vantage points represented by different interest 
groups (e.g., owner, user(s), designer, community and government authorities). 

The Building Type knowledge base is included in the Expert Design Advisor to provide 
prototype information relating to the type of building under consideration. In this context a 
prototype is defined as a body of knowledge relevant to the definition and solution of a related set 
of design problems. The prototype includes generalizations derived from specific instances, 
elements of previously tested solutions, decriptions of typical solution components, and solution 
boundaty constraints. The boundaries within which the prototype is applicable is provided by the 
Site/Neighborhood knowledge base, in terms of the requirements and characteristics of the owner, 
and the physical, environmental, social and economic context of the project location. 
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THE DOMAIN EXPERTS 


The current state of the design solution, represented as object descriptions (containing both 
geometric definitions and non-geometric attributes), drives six domain experts with evaluation 
capabilities in the areas of space access determination, construction cost projections, daylighting, 
sound control, structural system selection and thermal behaviour. Each domain expert, executing 
continuously in background under a separate process, extracts information pertaining to the 
particular design object under consideration from the available design knowledge bases and 
commences to evaluate the design solution based on its expertise (Fig.4). 

For example, the Lighting expert will evaluate the degree to which each space in the current 
design solution satisfies the requirement for daylight. The evaluation consists of two components. 
First, the requirements are established. This may be a trivial task, requiring only the generation of a 
simple query to a Reference database to obtain recommended task and background illumination 
levels for the type of space under consideration. Or, it may be a much more complicated 
undertaking involving the analysis of qualitative and quantitative design criteria such as: 

OWNER considers energy efficiency to be very important; 

USER GROUP (A) consider energy efficiency to be optional; 

USER GROUP (B) consider energy efficiency to be desirable; 

DESIGNER considers energy efficiency to be important; 

Recommendations for each SPACE based on past experience: 


x% of background illumination by daylight; 
y% of task illumination by daylight; 

Second, the Lighting expert will estimate the daylight illumination on the workplane at the 
center of each space in two parts. The Daylight Factor is estimated based on the geometry of the 
space, the geometry of windows in external walls and the reflectances of the internal wall, ceiling 
and floor surfaces. This Daylight Factor value is converted into an equivalent illumination level 
subject to an external daylight availability calculation for a particular month, day and time. 

The results obtained by each domain expert are added to the appropriate design object 
frames. In the current ICADS working model both the input and output templates of each domain 
expert are predetermined sets of attributes and only the values of these attributes are variable. The 
Conflict Resolver, resident in the Blackboard, examines the values posted by the domain experts 
and arbitrates conflicts. For example, the Sound expert may have generated the requirement that the 
north wall of the conference room should have no windows. This is in conflict with the current 
design solution (based on the Geometry Interpreter) and the Lighting expert who has determined 
that the '% of background illumination by daylight' for this room is already 15% below the 
'requirement'. Based on its own rules the Conflict Resolver determines that the windows in the 
north wall should be reduced by 20% and double glazed to minimize noise transmission. 
Apparently the reduction in the availablity of daylight is warranted in view of the noise 
transmission problem. 

The Blackboard posts these new values to the appropriate frames and thereby initiates a 
new round of evaluations by those domain expens whose previous results are now in conflict with 
the Blackboard's determination. If the Blackboard had decided that the windows must be deleted 
from the north wall of the conference room then it would have requested permission for this radical 
action from the designer. The interaction between the designer and the Blackboard is limited to 
extreme circumstances in the current ICADS working model. Such circumstances may arise: 

1 . If the decision of the Blackboard requires a modification of the drawing. In the above 
example, during the conceptual design stage a 20% reduction in the window area of the 
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north wall can be accommodated without modification of the 2-D representation of the 
space. However, the deletion of all windows from the wall would require the drawing to 
be changed. 

2. If the Blackboard cannot resolve a conflict set. Again, in the conference room example, it is 
conceivable that certain design specifications could mandate daylighting and sound control 
requirements that will not allow a compromise to be made. Under these conditions, the 
Blackboard will interrupt the designer and request guidance. 

At any time during this evaluation process the designer can request to review the current 
conflict state of the Expert Design Advisor (i.e., the interactions of the Conflict Resolver with the 
six domain experts). This is accomplished through the Design Interface on a second monitor. 


THE CONFLICT RESOLVER 

The Blackboard Control Expert is primarily implemented as the Conflict Resolver in the ICADS 
DEMOl model. While it is envisaged that 'planning' will play an important role in future 
implementations of the ICADS model, at this time the resolution of conflicts appears to be 
sufficient to coordinate the activities of the advisory components in the Expert Design Advisor. 

The principal purpose of the Conflict Resolver is to assert 'current value' frame slots, 
representing the current state of the evaluation process performed by the domain experts, onto the 
semantic network resident in the Blackboard. To accomplish this the Conflict Resolver requests 
from the Message Router all of the 'solution design object' frames which contain results generated 
by the domain experts. Current values fall into one of three basic categories: values which result 
from solutions proposed by a single domain expert; values which result from solutions proposed 
by several domain experts for a common current value; and, values which must be inferred from 
solutions proposed by several domain experts. 

In the case of the first category, which represents solution values unique to a single domain 
expert, the Conflict Resolver does not change the values proposed by the expert. The proposed 
solution values are simply asserted as current values into the appropriate frame slots. In the second 
category two or more domain experts propose differing values for the same solution parameter. In 
such direct conflict situations it is the responsibility of the Conflict Resolver to either determine 
which of the values is most correct or to derive a compromise value. The process of resolution may 
cause the Conflict Resolver to change several current values in addition to those in direct conflict. 
An example of such a change is given below: 

Structural expert: 'suggested roof material type' = A 

Climate expert: 'suggested roof material type' = B 

Rule 1: if A = B then 

current value 'suggested roof material type' = A 

Rule 2: if A == timber and B == concrete then 
current value 'suggested roof material type' = concrete 

Rule 3: if A == concrete and B = timber then 
current value 'suggested roof material type' = concrete 

and 

current value 'suggested roof struct.system' = concrete plate 

and 

current value 'required roof struct, depth’ = 4 

and 

current value 'roof insulation thickness' = 3 


108 



The Conflict Resolver incoiporates resolution rule sets which determine the best current 
values from those proposed. There is a resolution rule set for each possible direct conflict. In the 
development of each rule an attempt has been made to achieve a desirable balance between the 
various design issues. At this level the Conflict Resolver can be consider an expert whose 
knowledge is the ability to achieve this balanced integration. In the above example, let us assume 
that the Structural expert proposes 'timber' (A) and the Climate expert proposes ’concrete’ (B). 
Under these circumstances the Conflict Resolver recognizes that: 

- the solutions for the roof structure proposed by the Structural and Climate domain experts 
are substantially different; 

- the ’concrete’ solution proposed by the Climate expert suggests a need for thermal 
storage; 

- the ’timber’ solution proposed by the Structural expert cannot be readily modified to 
provide thermal storage; 

- in most cases a structural timber system can be replaced by a concrete system (there are 
exceptions to this rule of thumb (e.g., seismic risk) and the Structural expert should be able 
to recognize such circumstances and, if necessary, refuse to agree with the Conflict 
Resolver's proposed compromise); 

- the energy conservation savings provided by a passive thermal building are likely to 
exceed the higher capital costs of a concrete roof system. 

In the third category the Conflict Resolver deals with proposed solution values that are 
indirectly in conflict with other proposed solution values and current values. The resolution rules 
for this category allow the Conflict Resolver to make the necessary modifications to any of the 
values involved. Under these conditions, in addition to changing proposed solution values the 
Conflict Resolver may also change current values as shown in the following example. 

current value 'roof construction system' = A 
current value 'roof U-value (BTU/HR-SF-F)'= B 
current value 'roof insulation thickness' = C 
current value 'roof thermal lag (HR)' = D 

Climate expert: 'suggested roof construction system' = E 

Rule 1: if A o E then 

look up Reference database and change B, C, D to appropriate values for the suggested 
roof construction system 'E' 

In this example the Climate expert has suggested a new roof construction system. The 
Conflict Resolver recognizes that several current values must be changed so that they match the 
new roof construction system. Similar to the direct conflicts discussed under the second category, 
each indirect conflict must also have a set of resolution rules. 

Not all conflicts can be resolved by the system. In some cases, usually those requiring 
changes to the drawing or 'project design object' frames, the Conflict Resolver will ask for 
assistance from the designer. Under these circumstances operation of the Expert Design Advisor is 
suspended until the designer responds. 
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SOME IMPLEMENTATION ISSUES 


The model of the ICADS Expert Design Advisor described above presents several issues of 
concern that are of an operational nature. 

The first concern is to prevent the Conflict Resolver from entering into an 'endless 
argument' state that may arise when two domain experts always return with conflicting values for 
the same solution parameter. For instance, in reference to the previous example the Structural 
expert may insist for good reasons that the roof construction system should be 'timber'. For 
reasons that are different but just as persuasive, the Climate expert may be unwilling to deviate 
from its original proposal of a 'concrete' roof system. The two domain experts are now locked into 
an ad absurdum argument. In the current ICADS working model the Conflict Resolver monitors 
this type of situation by checking for repetitive cycles in current values. 

A second concern is related to the timeliness of the conflict resolution process. In the 
implemented model of the Expert Design Advisor, the Conflict Resolver will not post a current 
value to the Blackboard until it has seen all of the 'solution design object' frames which are 
involved in a given conflict. In a full ICADS implementation it may be desirable for the Conflict 
Resolver to post a current value based on partial information (i.e., based on only some of the 
required 'solution design object' frames). This current value could be updated when the Conflict 
Resolver receives additional information. In the implemented model the Conflict Resolver waits 
until it has all of the necessary values from the domain experts before asserting a new current 
value. 

The potential for a 'cascading' condition which may arise when a minor change by a 
domain expert causes a major re-evaluation of the current solution by several domain experts, is 
another concern. In the DEMOl implementation of the Expert Design Advisor the possibility of 
such a condition occurring is exacerbated because domain experts will fire on any change to a 
current value and the Conflict Resolver will respond to any proposed changes posted by the 
domain experts. An attempt has been made to forsee events that could conceivably lead to this 
undesirable condition. Where appropriate, tests have been included in the rules of domain experts 
to determine whether the current divergence between the most recent suggestion and the 
corresponding current value (proposed by the Conflict Resolver) is sufficiently large to warrant 
further action by the domain expert. 


CONCLUSION 

The implementation of the first prototype working model represents a three-year milestone in the 
ICADS project. Although ICADS DEMOl is limited in scope, it will provide a vehicle for the 
collection of a body of knowledge relating to the performance characteristics of a computer-based 
design environment. Extensive explorations can now be conducted to determine the impact of an 
Expert Design Advisor that dynamically responds to the actions of the designer in its continuous, 
unobtrusive evaluation of the evolving design solution. 
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